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(54) Printer driver switching in windows operating systems 



(57) An information distributing apparatus for oper- 
ating within a computer network environment (12). The 
information distributing apparatus includes a computer 
(10) having an operating system and is configured to 
operate within the computer network environment (12). 
The apparatus has an application (36) configured for 
running on the computer (10) via the operating system, 
the application (36) configured to generate a source job 
(28) in the form of an intermediate file format comprising 
an output instruction file (42). The apparatus includes a 
print processor (50) in the form of an Intermediate exe- 
cutable code for operating on the output instruction file 
(42). The apparatus also Includes at least one output 
device (14, 16. 18) having an output device driver (56) 
configured to convert the output instruction file (42) to 
output instructions usable by the output device (14, 16. 
18) for producing output. The print processor (50) is 
operable on the output instruction file (42) to select the 
device driver (56) of one of the at least one output 
device (14, 16, 18) to render the output instruction file 
(42), and feed the output instruction file (42) to the out- 
put device driver (56) of one of the at least one output 
device (14, 16, 18). A corresponding method is also dis- 
closed. 
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Description 

FIELD OF THE INVENTION 

5 This invention relates to a system for print driver switching within a computer network environment such as a win- 

dows operating system to direct print jobs to one or more unlike devices from a single print request withiin an applica- 
tion. 

BACKGROUND OF THE INVENTION 

10 

Centralized and decentralized computer networks are available with a wide variety of peripheral devices that are 
connected together so that they can communicate with each other. For applications requiring the output of data from a 
computer system, one or more output devices are provided in the form of a monitor, a printer, a disk drive, or other 
peripheral. For the case of computer networks, the number and variety ot available output devices can be quite large, 
15 resulting in data transfer incompatibility problems. 

One problem associated with current conputer network environments is that they do not allow the automatic send- 
ing of electronic material from one application to unlike destinations from a single source application or document. For 
example, current window driver solutions do not allow^an operator to automatically send a print job from a print driver 
to any one of several receiving devices, or printers. Instead, the operator must reconfigure the system to deliver output 
20 to a specific print driver of a selected output device. 

With current window driver solutions, each printer forms an output device having a dedicated print engine requiring 
dedicated encoding for the associated print processor. For e>ample, a print processor produces a file 6f drawing 
instructions for a configured printer. Normally, a permanent link is provided between the application (e.g., a word proc- 
essor), the intermediate drawing file, and a single, dedicated output device. Optionally, the user can select one of sev- 
25 eral dedicated output devices via a windows-based menu. However, such a configuration is formatted for use with one 
output device which the user has selected, and remains dedicated to such device until it is manually reconfigured. 

Therefore, a need exists for a system that distributes print jobs from a computer operating within a computer net- 
work environment to any one of several unlike output devices from a single print request within an application. 

Another problem associated with current computer network environments is the inability to send originating source 
30 data multiple times to multiple output devices. For example, current window driver solutions do not allow an operator to 
automatically parse the source data multiple times to obtain the necessary encodings for each output device. Instead, 
the operator must reconfigure the system to perform each delivery of output to each specific print driver of each 
selected output device. 

This invention relates to an information distributing apparatus and method which overcomes the above drawbacks. 
35 The information distributing apparatus of this invention improves distribution of source jobs for output to any one of mul- 
tiple unlike output devices. The information distributing apparatus of this invention also improves distribution of source 
jobs to multiple receiving output devices form a single source application/document. 

SUMMARY OF THE INVENTION , . 

40 - _ , 

According to one aspect of this invention, the information distributing apparatus depicted generally in Figs. 1-5 
operates within a computer network environment. The information distritxiting apparatus includes a computer having 
an operating system and is configured to operate within the computer network environment. The apparatus has an 
application configured for running on the computer via the operating system, the application configured to generate a 

45 source job in the form of an intermediate file format comprising an output instruction file. The apparatus includes a print 
processor in the form of an intermediate executable code for operating on the output instruction file. The apparatus also 
includes at least one output device having an output device driver configured to convert the output instruction file to out- 
put instructions usable by the output device for producing outpirt. The print processor is c^erable on the output instruc- 
tion file to select the device driver of one of the at least one output device to render the output instruction file, and feed 

50 the output instruction file to the output device driver of one of the at least one output device. 

According to another aspect of this invention, the information distributing apparatus depicted generally in Rgs. 1 -5 
implements a method for operating within a computer network environment. The method is implemented in a system 
for distributing print jobs from a computer usable for operating in a computer nehvork environment of the type having an 
operating system; an application configured for running on the c^erating system and generating a source job compris- 

55 ing an output instruction file; and at least one output device having an output device driver for receiving the output 
instruction file for producing output. The method inclLdes the steps of: providing a print processor in the form of an inter- 
mediate executable for operating on the output Instruction file; retrieving printer details for an identified printer driver 
name from a.memory location in a memory of the computer; changing the prtrter driver name in the memory to a dif- 
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ferent driver of a different printer; saving the printer details of the identified printer driver name in the form of new printer 
information in a system registry; retrieving printer document properties of the saved printer details from memory; 
changing the retrieved printer document properties to match new driver settings; saving the new printer document prop- 
erties in the system registry; and allocating and initializing print processor data structures usable to execute a print job 
5 on the new printer. 

Other objects, features arid advantages will be apparent from the detailed description given below of the apparatus 
and method of this invention and embodiments of systems which incorporate the apparatus and method of this inven- 
tion. 

10 DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a conceptual block diagram of a computer network environment for implementing the printer driver switch- 
ing mechanism and method of this invention, depicting one layout of a plurality of computers and output devices con- 
figured within the network environment in accordance with one embodiment of this invention. 
15 Fig. 2 is a schematic block diagram illustrating the structure and operation of the printer driver switching mechanism 
of Fig. 1 , depicting multiple parsing of the originating document in a format for single thread spool delivery of a source 
job to multiple destinations. 

Fig. 3 is a schematic block diagram illustrating the structure and operation of the printer driver switching mechanism 
of Fig. 1 , depicting multiple parsing of the originating document in a format for multiple thread spool delivery of a source 
20 job to multiple destinations. 

Fig. 4 is a schematic block diagram of a first emtxxliment of ,a device driver switching mechanism during a first pass 
operation frorn an original device/driver to spool enhanced metafile data to memory. 

Fig. 5 is a schematic block diagram of a first embodiment of a device driver switching mechanism during a second 
pass operation for despooling print job, and printer information viaia print processor to anew device driver. 
25 Fig. 6 is a schematfc block diagram of a first embodiment of a device driveriswitching mechanicm during a multiple 
pass print job distribution. • . c r., .. ;-;.r rs^ ^ ^ : : 

Fig. 7 is a flowchart illustrating the sequence of steps; employed in automatically implementing a mechanism for 
printer driver switching in windows operating systems to allow distribution^:crf print jobs to multiple unlike jobs within a 
print request within an application in one embodiment of the present inventioni : . 
30 Fig. 8 is a flowchart illustrating a first operation implemented by the print processor of Rg. 7. 

Figs. 9 and 10 illustrate a flowchart depicting a secorxJ operation implemented by the print processor of Fig. 7. 

Fig. 11 is a flowchart illustrating a third operation implemented by the print processorof Fig. 7. 

DETAILED DESCRIPT ION OF THE INVENTION . . o , : - - 

This disclosure of the inv'ention is submitted in furtherance of the constitutional purposes of the U.S. Patent Laws , 
"to promote the progress of science and useful arts". U.S. Constitution, Article 1 , Section 8. 

Figure 1 shows a computer 10, labeled "computer A", configured for distributing information within a computer net- 
work environment 12. Computer 10 is able to send electronic material in the form of a source document, or job to mul- 

40 tiple receiving devices within the network environment. The source document is generated in response to an application 
being run on an operating system of computer 10. More particularly, a plurality ofroutputdevrces 14, 16 and 18, labelled 
"output device A", "output device B", and "output device C!'; respectively provide the receiving devices for receiving out- 
put instruction files and producing output; Additionally computer 10 is linked with other computers 20 and 22 having 
similar associated output devices (not shown). Computer 10 is capable of sending a source documerrt to any one of 

45 these output devices. Computer .10 iS;: connected :tog ether, or linked: for signal communication with' each of output 
devices 14, 16 and 18 via a/espective coiruriunications link 24; Similarly,;' computer, 10 is c^^ together, or linked 
for signal communication with other cornputersi 20. and 22 viaa respective conimunrcations link 26. Links 24 and 26 can 
be formed from any of a number ;Df presently available wire. or wireless signal connections usable in forrhing computer 
network connections. One such connection is formed by hardwiring together respective components of network 12. 

BO According to the network environment 12 depicted in figure 1, it is understood that output devices 14, 16 and 18 
and computers 16, 20 and 22 have dedicated processors for performing processing and communications needs when 
transferring source jobs arwi output instructions between devices of the network. The computers 16, 20 and 22 have a 
Windows 95 operating system, and a custom print processor of this invention for use with Windows 95. The output 
devices 14, 16 and 18 have the same custom print processor, enabling printing directly from an application running 6n 

55 the operating system of computer 1 0 to any one of output devices 1 4, 1 6, or 1 8:: ^ 
Computer 10 preferably contains a Windows 95 operating system. An "operating system" is a set of computer pro- 
grams used specifically by a corrputer for managing its. resources: The operating system controls all resources of the 
computer system, including communication between a user and* the computer. Several exerdplary operating systems 
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include DOS, Windows, OS/2. UNIX, and the Macintosh System. Preferably, the Windows 95 operating system also 
includes the "Microsoft Windows 95 Device Driver Developers Kit" which can be obtained from Microsoft Corporation 
by ordering their "Microsoft Developer Network Professional Subscription". TTie mailing address is: Microsoft Develop- 
ers Network, PO. Box 5549, Pleasanton, CA 94566-1549. The "Microsoft Developer Network Professional Subscrip- 

5 tion" includes CDROMs with sample source code and documentation describing how to develop applications and 
device drivers. One component of the Driver Developers Kit (DDK) details how to develop print system components. A 
print processor is a print system component documented in the Driver Developers Kit. The subscription includes alt doc- 
umentation as to how to use the Developers Kit. . 

According to the implementation of this invention, an application is run on the operating system of computer 1 0, as 

10 shown in Figure 1. An "application" is a computer program that is configured to assist in performing a certain type of 
work. In contrast, an operating system runs a computer, a utility performs maintenance or general-purpose chores, and 
a language is used to create computer programs. Based upon its particular design, an application can manipulate text, 
graphics, numbers, or a combination of these elements. 

The operating system of computer 10 and network 12 includes an application programming interface (API). An API 

15 comprises a defined set of functions provided by the operating system for use by an application. The interface exists in 
the form of a defined set of functions for use where it is necessary for proprietary application programs to talk to com- 
munications software, or conform to protocols from another vendor's product. An API provides a standardized method 
of vertical communications within and outside of the network environment. 

For the case where output devices 14, 1.6 and 13 are printens, each printer has a printer driver. A "printer driver" is 

20 a software program that enables other programs to work with a particular printer without concerning themselves with 
the specifics of the printer's hardware and Internal language. Each printer requires a specific set of codes and com- 
mands to operate properly and to provide access to special features and abilities. Alternatively, where the output device 
is not a printer, the output device has a device driver that functions like a printer driver. 

A "driver", as referred to in a device driver and a printer driver, is a program or subprogram that is written to control 

25 either a particular hardware device or another, software routine. The term "driver" originated from the concept of har- 
ness race drivers or automobile drivers who put their steeds or cars through their paces in order to measure their capa- 
bilities. The most common examples of a hardware driver, one that controls hardware, are those that pertain to 
particular brands and models of printers attached to personal computers. For example, a specific printer driver allows 
a word processor to communicate with a particular model dot matrix printer or laser printer. 

30 Another import aspect involves the need for softWrare in the form of printer driver software for supporting output 
devices. Up to this point, only the mechanical aspects of a printer have been detailed. On another level, the problem is 
made more complex by the vast variety of printers, with all sorts of special features, produced by a wide variety of man- 
ufacturers. 

In the early development of prir^ers, the situation was fairly simple. The available printers responded to ASCII text 
35 and control characters. For each character sent to the printer, a letter was produced. Advancement to the next line of 
text was made by means of a carriage return and line feed character. If overprinting was needed for boldface effects, 
only a carriage return character was sent, and the line was reprinted. Typewriter-like printers were also available, which 
responded to a backspace character, so boldfacing and underlining were easily accomplished. 

As printer technology advanced with the development of dot matrix printers, the capability for font changes and 
40 graphical options became feasible. The outcome of this advancement was that word processors needed a set of soft- 
ware for each available printer, as each manufacturer had its own ideas of which features might be useful, each manu- 
facturer implemented them in a different way. With each new printer make or model, a new set of software, referred to 
as driver software, was needed. As a result, an awkward problem was produced for both the user of the word processor 
printer and word processor vendors. 
45 As the need for more elaborate printing capabilities has grawn, a number of solutions h^s arisen. The main problem 
has been deciding where tc put the "intelligence" for the printing process. There are three choices: 

1. In the word processor itself. The word ;processor becomes somewhat awkward to Use unless a fast CPU and 
good interface are available. Among other things, this leads to a proprietary file format for the word processing doc- 

50 ument. It becomes awkward to move highly formatted documents between different platforms or word processors, 
unless a common data format can be used, such as RTF or DCA. If no common formatted data structure can be 
found, it may be possible to transfer the files in "generic" format, where a carriage return/line feed is used only at 
the end of a paragraph. It Uien becomes necessary to reformat the file. 

2. In the printer. This leads to what are known as page description languages (PDLs). The most common of these 
55 is one known as PostScript. The printer contains a processor and program to interpret the commands contained in 

the PostScript output file. The PostScript output file is an ASCII text file that can be edited manually if necessary 
Other proprietary page description and contro! languages are also available, such as those in the Hewlett-Packard 
line of laser printers. The postscript implementation is activated by buying arid installing a PostScript language chip 
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for the printer. , - . 

3. Another alternative. A final alternative, intermediate to these two, is a typesetting program such as TeX that cre- 
ates a file containing the typesetting commands. This file is then converted into a device-independent format that 
must be passed through a driver program for the particular printer. 

In addition to placement of the intelligence, graphics support is implemented in two general ways: 

1 . Essentially a graphics "dump" of the word processing screen. Again, the necessary printer driver is needed 
for the printer being used. It is also possible to imbed the art within the document itself, such as in Microsoft Word. 
10 2. An "encapsulated" PostScript file. This contains the code created by the drawing program in a format to be 
interpreted. An Encapsulated PostScript file can also contain a preview image of the picture in a raster format, such 
as TIFF, or vector format, such as a Windows metafile for simple but direct screen nranipulation of the image. 

Again, which method is chosen is a matter of personal preference, and the particular implementation available. For 
15 purposes of implementing Applicant's device and method of Figures 1-11, a custom print processor for use with an 
operating system such as Windows 95 is used with a printer driver for the operating- system that supports creating Win- 
dows enhanced metafiles. 

Figures 2 and 3 illustrate ways for delivering a source job 28 to one or more destinations 30, 32 and 34, with one 
example of a destination being output devices 1 4, 16 and 18 (of Fig. 1). Another example of a destination could be com- 

20 puters 20 and 22. Current Windows driver solutions do not allow sending from one application to multiple destinations. 
However, the driver must be able to send electronic material to multiple receiving devices from a single source applica- 
tion/document in order to be effective. This^requires saving the originating document data, or source job 28. in a format 
that can be parsed multiple times to obtain the desired encodings as shown in Figure 2. If the source document, or 
source job 28. is multiple pages, then the mechanism to, send must support sending all of a destination's pages before 

25 going to the next encoding type as shown in Figure 3; A multiTthread delivery mechanism is necessary to implement the 
sourcejobdeliverytomultipledestinations. as depicted in Figures. -iv.: . . ; c , 

As shown in Figures 2 and 3. there exist multiple options for :delivering a source job 28 to multiple destinations 30, 
32, and 34. Following is a summary of the options for sending: . ^ \ „ : ' ' 

30 1) All pages of a job can be sent to a particular destination before delivery to other destinations. This option is 
referred to as serial delivery to one destination at a time via single-thread spool delivery Current Windows driver 
architecture uses such single-thread spool delivery. : 

2) Delivery can be implemented one page at a time to each (all) destination(s) before going to the next page of the 
source job. However, problems may delay delivery which means that it-is often not a good delivery choice. 
35 3) A thread can be. provided for each destination (niultiplerthread)..with the entire job being delivered by each 
thread. In this manner, all threads can run simultaneously, resulting in parallel execution. vThis requires changing 
windows despooling mechanisms, i>ut;offei5 the best delivery to all rec^^ 

The implementation of an intermediate-file format,- preferably embodied in one form as an enhanced metafile 

40 (EMF). would allow the multiple passes necessary to implement the above-mentioned delivery features of Figures 2 
and 3. However, an enhanced metafile is typically written to a memory via a spooler, and spooler play-back of an 
enhanced metafile does not allow multiple pass delivery from the memory. Anr enhanced metafile (EMF) is an enhanced 
file format that describes a series of graphical operations in a:high-level, device-independent data format. 

In order to implement such an intermediate file format, a custom print processor of Applicant's design will solve this 

45 problem by copying the enhanced metafiles. As will be shown and described below with reference to Figures 4-6, such 
a custom print processor will enable multiplep^isses to be delivered; from memory;via:a spooler/despooler to deliver a 
source job to multiple destinations via the delivery schemes disclosed above with reference to Figures 2 and 3. A 
"spooler" is a component that takes application gen^ratedoutput intendad for a printer and stores it temporarily on disk. 
A "despooler" is a system conrponent responsible for data in spool files and handing it to the software responsible for 

50 writing it to an output device. r ; i ^ 

However, in order to do this, the device of this invention needs a dedicated spool job header f ileio describe the des- 
tinations and rendered encodings for each destination. When a Despoot operation is implemented, Graphics Device 
Interface (GDI) sends graphical functions within a device context (DC) through the, printer driver to the spooler; A "GDI" 
is a Graphics Device Interface (GDI), the component of Windows responsible for implementing the graphical functions 

55 such as line drawing and color management. GDI is a dynamic link library (DLL) that includes all of the graphical appli- 
cation program interlaces (APIs) in Windows. A device context (DC) is a GDI data structure that describes the current 
state of a device or drawing surface, a logical object rfQund at,the application level. More specifically, a device context is 
a structure maintained internally in GDI for the.purposepf displaying theigraphiqaldata^painting on the screen, or print- 
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ing pages). Any application developer who deals with printing is familiar with the conc^t of a device context. A dynamic 
link library (DLL) is a library of shared functions that applications link to at runtime, as opposed to compile time. A single 
in-memory copy of the dynamic link library (DLL) satisfies requests from all callers. 

For source documents that are only one page in length, it is possible to alternatively use raw data formatted into 
5 the printer's language instead of the enhanced metafile (EMF). However, in this case it is necessary that aH destinations 
support and choose the same encoding. In order to do this, support of the enhanced metafile is flagged in GDIINFO 
structure. 

The apparatus and method of this invention deliver data to devices, including output devices such as printers, scan- 
ners and plotters, in a distribution list. The distribution list is a list of devices that may receive output. A distribution list 
10 may be controlled by a separate application, with which the print processor communicates. The separate application 
could be on any of a number of devices present within a computer network environment. The print processor then uses 
the list of devices when implementing operation of driver switching according to the device and method of this invention. 

Applicant has tested the operation of driver switching according to this invention by running the program and file 
provided in Table 1 , below. Further details of the implementation will be discussed below with reference to Figures 4-6, 
15 and the flowchart of Figures 7-11. Applicant ran such test on a Windows 95 system. An EMF job was put in a queue 
with 5 drivers, then the drivers were switched through a user interface (Ul) to a bitmap driver. The resulting source job 
was processed, switched, and released, with the print job properly printing to a file. 

The C code program listed below in Table 1 provides a "Custom Print Processor for Driver Svvitching" according to 
this invention. This code, as detailed in the flowcharts of Figures 7-11, enables the switching of components in the form 
20 of output devices lor receiving a print job. The switching of components is implemented via a custom print processor for 
Windows 95, a driver that creates a windows bitmap, and a driver that creates HP PCL5 printer language. In order to 
do this effectively, a printer driver for Windows 95 or NT must support creating WirxJows Enhanced Mela Files (EMFs). 
An operator need only run a windows application, selecting the desired print object, with the desired initial printer driver. 
However, this driver must have the custom print processor associated with it. The operator, or network via some prior- 
25 itization scheme, can then print the print job directly from the appiication. The resulting print job is stored temporarily in 
the spooler. When the job is scheduled to print, the spooler invokes the custom print processor to print the job. The print 
processor queries the system to determine if the drivers exist. It then opens the printer selected by the application and 
gets the cunrent PRINTER.iNFO.2 structure to get the driver name and other information about the printer. 

The print processor then changes the driver name to the new desired name by using "SetPrinter API" with the 
30 PRINTER.INFO.2 stmcture and a new driver name field. Then using "Document Properties", the print processor gets 
the new driver's DEVMODE structure so it will be used and understood by the new driver. This is also saved on the 
PRINTER.INFO.2 structure. The above is all done when the print processor is instructed to "open the processor by the 
spooler. The processor then gets called by the spooler to process the data. The processor calls the graphics device 
interface (GDI) to process the enhanced metafile (EMF) data in the new driver. At the end of the job, the driver is reset 
35 to the original so the user is always presented with the same information. 

In order to implement the above process, several constraints need to be applied. First, the DEVMODE for any driver 
used cannot rely on private DEVMODE data, unless ail drivers support the same private data as it is included in the 
enhanced metafile (EMF) job. SecorxJIy, the user interface for ai! drivers should look the same, because the user could 
be invoked anytime. 

40 In order to better understand driver switching according to the apparatus and method of this invention, a step-by- 
step flow through the system as implemented via the algorithm of Table 1 will be reviewed vwth reference to Figures 4- 
6. A basic benefit of the dt sver switching according to this invention is to allow a system choice of a different printer driver 
than the one used to create a print job in Winda^vs 95 or NT (this applies to the OS/2 Queue Processor (queue driver) 
in concept as well). Choosing a different driver allows the single-spooled job to be sent to multiple unlike devices such 

45 as an HP Desk Jet printer, a LaserJet printer or a Plotter. It can also be processed multiple times to send to a distribution 
of devices, such as networked printers or Internet devices. 

An analysis of the driver switching job flow illustrated in Figures 4-6 begins with a first pass print request that is ini- 
tiated via an aii^lication 36. Application 36 producesa print job, 6r source job. that is delivered to the dynamic link library 
(DLL) of a graphics device interface (GDI). The graphics device interface (GDI) implements shared functions at linktime 

50 between the application 36 atxl an original driver 38. The graphics device interface (GDI) contains all of the graphical 
application program interfaces (APIs) in Windows, producing spooled data in the form of an enhanced metafile 42. 

According to a second pass operation of the driver switching. Figure 5 illustrates spooler 46 which directs via a 
spool header 48 the storage and retrieval of the spooled print data, or enhanced metafile 42. from memory device 44. 
Spooler 46 passes print job and printer information to the custom print processor 50 of this invention. More particularly. 

55 the print processor 50 via the code implementation of Table 1 and Figures 7-1 1 resets the driver from the original driver 
38 (of Fig. 4). A registry 54 stores hardware and software configuration information that is retrieved and used by the 
system application program interfaces (APIs) to assist le print processor 50 in resetting the driver. Theprint processor 
50 directs the graphics device interface (GDI) to deliver the print job on a new, or reset driver. The enhanced metafile 
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(EMF) 42 is retrieved from memory device 44 by the graphics device interface (GDI) to form part of the "GDI play spool 
stream". The graphics device interface (GDI) directs communication with the new driver 56 and a port monitor/print pro- 
vider 58 of an output device 14. Device 14 subsequently receives output instructions from driver 56. which are con- 
verted from the output instruction file comprising a drawing instruction file containing drawing instructions that Is 

5 received from print processor 50. Print processor 50 feeds the output instruction file to the output device driver 56 based 
upon a prioritization scheme. . . 

One suitable prioritization scheme involves directing the output instruction file from print processor 50 to one of the 
at least one output devices based upon the print capabilities of the output device 14. Another way is to base directing 
the output instruction file to an output device based upon the relative availability of the output device 14 and/or the 

10 related device driver 56. For example, a particular driver 56 and printer 14 might contain too many print jobs already in 
queue. Alternatively, the driver 56 and printer 14 might be out of paper or ink. . Even further, the particular driver 56 and 
printer 14 might not have desired print capabilities such as color, correct sized paper, image resolution, etc., making it 
more sensible to have processor 50 to deliver the print job to another more suitable driver and device, base upon one 
or any of a number of known prioritization schemes. . 

15 Considering a particular driver 56 and device 1 4 being used, how each method works depends on the printer driver 

used by the word processor, A driver is an extension to the operating system and is tailored to a specific piece of hard- 
ware, such as a Hewlett-Packard LaserJet III printer or a super VGA display. The printer driver takes the information pro- 
vided by the in-line stream of data or the page description language and converts it into low-level commands recogr.lzed 
by the printer. (A screen driver does the same with the video adapter to display text on the monitor.) By working with 

20 different drivers, a word processor can work with the same document on a variety-of displays and printers. A "registry" 
is a structured file in Windows that stores indexed information describing the host system's hardware, user preferences, 
and other configurations data. The registry serves to reduce the proliferation of configuration files that can plague a > 
Windows machine. . : = - • . . 

Figure 6 illustrates driver switching for distributing multiple. pass jobs to one or more output devices. Print processor 

25 50 is "opened" by spooler 46, according to Step "S7.20" described below with.reference to Figure 9, in order to copy 
the original enhanced metafile (EMF) 42 which is stored In memory device 44., Spooler 46 also directs the print proces- 
sor to print the document on the print processor, via block 50. and Step "S7.30 of Figure 1 1 . Operation block 50 Imple- 
ments a closed loop 62 that points to a new print job 64, and retrieves and rewrites to memory 44 the enhanced metafile 
42, which is re-retrieved via the print processpr of delivery to each of a series of output devices according to loop 62 

30 and pointer 64. . 

Logic Flow Diagram. 

According to Figure 7, a "print processor" is disclosed as a first level logic flow tliagram for the programming of a 

35 computer for operating within a conoputer network environment to render print jobs; to multiple output devices. Table 1 
further details the implementation of the print processor rendered in C-cod^ |anguage..as sha^vn above with reference 
to Figures 5 and 6. The; "print processor" forms a device that implements printer driver switchirig for use with a computer 
operating within a computer network environment. . The;"prlnt propessor":can;be implemented automatically according 
to the logic flow diagram of Figures 7-11. Alternatively, the custom print processor can create HP PCL5. In this manner, 

40 the print processor supports the creating of Windows Enhanced Meta Files (EMFs). A user runs a windows application, 
selecting a desired print object, with a desired initial printer driver. The device drivers operating In the computer network 
environment must have the custom print processor associated with them. Print jobs are printed form the application. 
The resulting print job is temporarily stored via the spooler in. memory When the job is scheduled to print, the spooler 
invokes the custom print processor to print the job. The print processor queries the system to determine if the drivers 

45 exist. It then opens the printer selected by the application and gets the current PRINTER. INFO. 2 structure to get the 
driver name and other information about the printer. The print processor then changes the driver name to a new desired 
name as previouslydisclosed. . r : ^ : ^ ■ :v"';> 

According to Step "Si", the operating.systems on the cornputers wifriiq the co^ networK and the 

operating systems and device drivers of the putput devices . are started. For example, upon powering up each device in : 

50 the network, the system BIOS starts the operating system and spooler which can be used to automatically initialize, or 
trigger the initiation of the flowchart of Figures 7 and 8. which causes the computer to create an enhanced metafile, col- 
lect original printer drive device information, and switch the printer (or output device) for receiving the metafile. After per- 
forming Step "Si", the process proceeds to Step "S2". 

In Step "S2", the application running on the operating system initiates a print job. One way is to automatlcally gen- 

55 erate a print request. Another way is for a user to request a print job. After performing Step "S2", tfie process proceeds 
toStep"S3". . ^ ^ 

In Step "S3", the application running on the operating system fonwards the print job to the Graphics Device Interface 
(GDI), a component of the Windows operating system, responsible for implementing the graphical functions such as lino 
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drawing and color management. The GDI generates data in intermediate drawing instructions In the form of enhanced 
metafiles. After performing Step "S3", the process proceeds to Step "S6". 

In Step "S4", the original printer driver provides device information necessary to operate the associated peripheral 
device such as a printer, a monitor, or other output device. The printer driver provides information about capabilities of 
5 the device that it represents. For example, the size of paper being used, support of colors, monochrome, etc. are some 
of the information about device capabilities that can be provided. After performing steps "S4" and "S5". the process pro- 
ceeds to Steps "S5" and "S6". 

In Step "S5", the GDI transfers the generated intermediate drawing instructions in the form of an enhanced metafile 
where it is stored in memory. 

10 In Step "S6", the process directs the spooler to initiate a second pass on the print job in order to send the memory 
stored print job to an output device, as determined by the application. After performing step "S6", the process proceeds 
to Step "S?". 

In Step "S7", the process initiates implementation of the print processor. The print processor is implemented in one 
of three ways: the print processor is initialized via operation of the flowchart depicted in Figure 8; the print processor is 
15 opened, printer driver details are retrieved, and new printer drive settings are saved in the system registry to achieve 
print processor data structure: and the print processor carries out the printing (or output) of a print job on the new output 
device via an associated device driver. After performing Step "S7" (one of the routines of Figures 8. 9 and 10 collec- 
tively, or 1 1), the process proceeds to Step ''SS". 

In Step "SB", the GDI renders the print job using a new printer driver. After performing Step "SB", the process pro- 
20 ceeds to Step "S10". Encircle numeral 1 connects with Step "S7.36" for passing a buffer to GDI. according to the oper- 
ations of Figure 1 1 . After performing Step "SB", the process proceeds to Step "Si 0". 

In Step "S9". the new printer driver, selected by the application, provides output device Information :o GDI. enabling 
the GDI to render the print job to enabling output of the print job via step "Si 0". 

In Step "SI 0", the print job is printed as a document. At this point, the process terminates. 
25 According to Figure 8, the print processor implements a first operation. According to Step "S7.1 0". the process Ini- 
tializes the print processor function pointers and allocates memory After performing Step "S7.10". the process pro- 
ceeds to Step "S7. 1 1 ". 

In Step "S7.1 1", the print processor implements a first operation. According to step "S7.10", the process initializes 
the print processor function pointers and allocates memory After performing Step "S7.10", the process proceeds to 
30 Step"S7.ir'. 

In Step "S7. 1 1 the process initiates return to the spooler. After performing Step "S7. 1 1 the process proceeds to 
Step ''S7. 12". 

In Step "S7.12", the process ends. The process then proceeds to Implementation of the flowchart of Figures 9 and 

10. 

35 According to the process of f^igures 9 and 1 0, ihe process implements a second operation by the print processor. 

According to Step "S7.20", the process opens the print processor. After performing Step "S7.20", the process proceeds 

to Step "S7.2r. . . _ .- . . . : 

In Step "S7.21 ", the print processor opens the printer. According to Step "S7. 1 0", the process initiates the opening 

via "openprinter API". "Openprinter API" is the name of the subroutine that the print processor calls in the "Microsoft 
40 Windows 95 Device Driver Developers Kit". The "openprinter API" exists In the spooler to perform functions required by 

the spooler. After performing Step "S7.21 ", the process proceeds to Step "S7.22". 

In Step "S7.22", the print processor reti-ieves printer details using "printerinfo2 structure". According to Step 

"S7.22", the details are retrieved via "getprinter API". "Getprinter API" is the name of a subroutine in the spooler that 

retrieves information from the spooler. After performing Step •'S7.22", the process proceeds to Step "S7.23". 
45 In Step "S7.23", the print processor changes the printer driver name in "printlnfo2" structure to a new device driver. 

After performing Step "S7.23", the process proceeds to Step "S7.24". 

In Step "S7.24", the print processor saves the new printer information in the system registry. Such is implemented 

via "setprinter API". "Setprinter API" is a subroutine that exists in the spooler that saves information about the printer, 

or output device, so that the spooler has knowledge of the Information. After performing Step "S7.24", the process pro- 
50 ceeds to Step "S7.25". 

In Step "S7.25", the print processor retrieves the printer document properties. The retrieval is implemented as "doc- 
umentproperties API". "Documentproperties API" obtains information from the spooler about documents being gener- 
ated. After performing Step "S7.25", the process proceeds to Step •'S7.26". 

In Step "S7.26", the print processor changes the document properties to match new driver settings. The print proc- 
55 essor essentially updates the devmode structure. "Devmode structure" Is stmcture that exists in the spooler that 
describes the capabilities of the printer drivers available within the computer network environment. After performing 
Step "S7.26". the process proceeds to Step "S7.27". 

In Step "S7.27", the print processor saves the new printer document properties in the system registry. To do this. 
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the print processor changes the driver name to the new desired name by using "setprinter API". "Setprinter API" is a 
subroutine that exists in the spooler that saves information about the printer, or output device, so that the spooler has 
knowledge of the information. After performing Step "S7.27", the process proceeds to Step "S7.28". 

In Step "S7.28", the print processor allocates and initializes print processor data structures. After performing Step 
5 "87.28". the process proceeds to Step "S7.29". 

In Step "S7.29", the print processor initiates a return to the spooler. After performing Step "87.29", the process pro- 
ceeds to Step "87.291". 

In Step "87.291". the print processor ends the subroutine of Figures 9 and 10. preferably moving on to implemen- 
tation of the subroutine of Figure 11. 
10 According to the process of Figure 1 1 , the process implements a third operation by the print processor. According 
to Step "S7.30", the process prints a document from the enhanced metafile. More particularly, the spooler directs a print 
document onto the print processor. After performing Step "S7.30". the process proceeds to Step "87.31". 

In Step "87.31 the print processor validates incoming parameters. For example, the print processor validates the 
printer handle and the data type. After performing Step "S7.31 the process proceeds to Step "87.32". 
15 In Step "87.32", the print processor opens the printer. After performing Step "87.32", the process proceeds to Step 
"S7.33". . ■ : , , , 

In Step "87.33". the print processor sets the spooler to start, and reads the document. More particularly, the "start- 
docprinter API" file is implemented. "Startdocprinter API" is a function that exists in the print processor that in turn is 
called by the spooler to irxiicate the start of a document to the print processor. After performing Step "87.33". the proc- 
20 ess proceeds to Step "87.34". 

In Step "87.34", the print processor reads a buffer of an enhanced metafile. After performing Step "S7.34", the 
process proceeds to Step "S7.36". ^ :^ ■ ^ ^ ' 

In Step "87.35", the print processor transfers the enhanced metafile to a buffer where it is read. After performing 
Step "S7.35". the process proceeds to Step "87.36". ;: 
25 In Step "87.36", the print processor passes the buffer to the GDI for the new driver to render. The "GDIplayspool- 
stream API" file is implemented. "GDIplayspoolstrean> API" is a sulwoutine that exists in the GDI. After performing Step 
"87.36*'. the process proceeds to Step "87.37". . 

In Step "87.37". the print processor proceeds until reaching the end of the file. After performing Step "87,37", the 
process proceeds to Step "S7.38". 
30 In Step "87,38", the print processor closes the printer. After performing Step "87.38". the process proceeds to Step 
"87.39". ^ 

In Step "87.39", the print process ends the subroutine of Figure 1 1 . returning back to implementation of the sub- 
routine of Figure 7. 

In compliance with the statute, the invention has been described in language more or less specific as to structural 
35 and methodical features. It is to be understood, however, that the invention is not limited to the specific features shown • 
and described, since the means herein disclosed comprise preferred forms- of putting the invention into effect. The 
invention Is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims 
appropriately interpreted in accordance with the doctrine of equivalents. ; 
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TABLE 1 

/* The following code is based on sample print processor provided by Microsoft 
Corporation in their Windows 95 Device Driver Developer Kit, The sample code 
is assumed to be freely available for modification and adaptation as necessary 
by device manufactures for devices to be used on the Microsoft Windows 
Operating System. Modification made to test the idea of PRINTER DRIVER 
SWITCHING are noted below with the following comment before and after the 
modification. The Microsoft copyright statement below does not apply to code 
within the comments. */ 

/*** > > Modification to test Printer Driver Switching. Begin/End << *♦*/ 
/*** >> L. Snyders 8/29/96 Copyright 1996 Hewlett-Packard Company < < 



/ 



* THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT 
NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR 
FITNESS FOR A PARTICULAR PURPOSE, * 

* ♦ 

* Copyright (C) 1993-95 Microsoft Corporation. All Rights Reserved. * 



************•***/ 

#define TIMING 

^include < windows. h> 
#include <wingdi.h> 
#include <winspool.h> 
#include <winsplp.h> 
#include <winuser.h> 
#inc!ude <winbase.h> 

#include "local. h" 
#include "winprint.h" 

TCHAR FAR *szWsnPrint =^ TEXT("WinPrint"); 
LPTSTR Datatypestl = {"RAW", "EMF", 0}; 
LPTSTR pSimple = NULL; 
LPTSTR pFuli = NULL; 
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/••• > > Modification to test Printer Driver Switching. Begin < < *♦•/ 
/♦•♦ > > L. Snyders 8/29/96 Copyright 1996 Hewlett-Paclcard Company < < 
•••/ 

LPTSTR pNewPrintierName = NULL; 
LPDEVMODE pDeviS/lode = NULL; 

/••• > > IVIodification to test Printer Driver Switching. End <<•••/ 
/••• >> L. Snyders 8/29/96 << ♦*•/ 



HDC WINAPI gdiPlaySpoolStrearrt(LPSTR; LPSTR, LPSTR, DWORD, LPDWORD, 
HDC); 

#define PRINTPROCESSOR_TYPE_RAW 0 
#define PRiNTPROCESSOR_TYPE EMF 1 
#define PRINTPROCESSOR_TYPE^NUM 2 

#ifdef TIIV/IING 

HWND hWndBench = 0; - 

#endif ' ^'-^'''^''^'^ - ' ■ ■ ' ' 



// • ■ • • .■ ■: .. . •• • ■. 

// 

BOOL 
WINAPI 

InitializePrintProcessor ( 

LPPRINTPROCESSOR pPrlntProcessor, 
DWORD cbPrintProcessor 

) ' •■■ ■ 

{ 

char szBuf[MAX_PATHl; 

pPrlntProcessor- >fpEnumDatatypes = 
WinprintEnumPrintProcessorDatatypes; 

pPrlntProcessor- >fpOpenPrintProcessor = WlnprlntOpenPrintProcessor; 

pPrlntProcessor- > fpPrintDocument = 
WinprintPrintDocumentOnPrintProcessor; 

pPrlntProcessor- >fpClosePrintProcessor = WinprintClosePrintProcessor; 

pPrlntProcessor- >fpControlPrlntProcessor='WlnprlntControlPrintProcessor; 

if (LoadString(hlnst, IDS BANNERSIIVIPLE. szBuf, slzeof(szBuf))) 
pSimple = AliocSplStr(szBuf); 
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If (LoadString(hlnst, IDS_BANNERFULL, szBuf, sizeof(szBuf))) 
pFull = AllocSplStr(8zBuf); 

return TRUE; 

} 



// 

// 

BOOL 
WINAPI 

WinprintEnumPrintProcessorDatatypes( 
LPTSTR pName, 
LPTSTR pPrintProcessorName, 
DWORD Level, 
LPSTR pDatatypes, 
DWORD cbBuf, 
LPDWORD pcbNeeded, 
LPDWORD pcReturned 

> 
{ 

DATATYPESJNF0_1 FAR 'plnfol = (DATATYPESJNFO_1 FAR 
•)pDatatypes; 

LPTSTR FAR *pMyDatatypes = Datatypes; 
DWORD cbTotal = 0; 
LPBYTE pEnd; 

•pcReturned = O; 

pEnd = (LPBYTE)plnfol + cbBuf; 

while (*pMyDatatypes) { 

cbTotal += wcslen(*pMyDatatypes)»si^eof.(TCHAR) + sizeof(TCHAR) + 
sizeof (DATATYPESJNFO_1 ); 

pMyDatatypes + + ; 
} 

* pcbNeeded = cbTotal; 
if (cbTotal < = cbBuf) { 
pMyDatatypes = Datatypes; 
while (*pMy Datatypes) { 
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pEnd-= wcslen<*pMyDatatypes)*sizeof(TCHAR) + sizeof(TCHAR); 
wcscpy((LPTSTR)pEnd, *pMy Datatypes); 
plnfo1->pName = (LPTSTR)pEnd; 
pinfol + +; 
(*pcReturned) + +; 

pMyDatatypes+ +; 

} 

} else { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
return FALSE; 

} . 
return TRUE; 



// 

// 

HANDLE 
WINAPI 

WinprintOpenPrintProcessor( 
LPTSTR pPrinterName 

) 
{ 

PPRINTPROCESSORDATA pData; 
HANDLE hPrinter = NULL; 
HDC hDC = 0; 

/•*• > > Modification to test Printer Driver Switching. Begin < < ***/ 

/••• >> L. Snyders 8/23/96 Copyright 1 996 Hewlett-Packard Company 
*••/ -r ■ 

DWORD dwBytesNeeded = O; /* for Get/SetPrinters •/ 
DWORD dwDMBytesNeeded = O; 
DWORD dwModeFlag = DM_OUT_BUFFER; 

BOOL bRetcode = TRUE; 

PRINTERJNF0_2 'pPrtlnfoZ = NULL; 

char buf(2561; /* buffer for debug strings •/ 
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OutputDebugString("HPPRINTP: Request to Open printer:"); 
OutputDebugString(pPrinterName); 

/*•* > > Modification to test Printer Driver Switching. End < < •••/ 
/♦•• > > L. Snyders 8/29/96 < < •••/ 



if (IOpenPrinter(pPrinterName, fithPrinter. NULL)) 
{ 

OutputDebugString("HPPRINTP.DLL Open Printer failed"); 
return FALSE; 

} 

/*•• > > Modification to test Printer Driver Switching. Begin < < •••/ 
/*•• > > L. Snyders 8/29/96 Copyright 1996 Hewlett-Packard Company < 



// 

// Call GetPrinter first to get byte count needed for buffer 

// . , .. , 

GetPrinter (hPrinter, 2, 0, 0, &dwBytesNeeded); 

// 

// Allocate memory for printer info buffer 
// 



if (l(pPrtlnfo2 = (PRINTERJNFO_2 •) AllocSplMem (dwBytesNeeded))) 

OutputDebugString("HPPRINTP.DLL AllocSplMem failed\n\r"); 
return FALSE; 

} . 

// 

// GetPrinters level 2 ■ 
// 

bRetcode = GetPrinter (hPrinter, 2, (LPBYTE)pPrtlnfo2, dwBytesNeeded, 
&d wBytesNeeded) ; 

if (bRetcode = = FALSE) 

{ •■• -■ . > - ■ . • 

OutputDebugString("HPPRiNTP.DLL Second GetPrinter failed\n\r"); 
return FALSE; 

} ■■ •.. - ■ • . •■ ■ ■ • - 

// 

// Change the driver to the mono bitmap driver 
// 
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pPrtlnfo2->pDriverName = AllocSplStr("Mono Bitmap Driver"); /♦ New 
Driver name */ 

bRetcode = SetPrinter(hPrinter, 2, (LPBYTE)pPrtlnfo2, 0); 
If (bRetcode = = FALSE) 

{ 

OutputDebugStringCHPPRINTP.DLL SetPrinter failed\n\r"); 
return FALSE; 

} 



// 

// Set the new driver's devmode structure, first get its size 
// 

dwDMBytesNeeded = DocumentProperties(NULL, hPranter, pPrinterName, 

NULL, NULL, 0); 
pDevMode = (LPDEVMODE)AIIocSplMem(dwDMBytesNeeded); 

// 

// Then get the default devmode values 

// _ 

bRetcode = DoGumentProperties{NULL, hPrinter, pPrlnterName, 

pDevMode, NULL, dwModeFlag); 
if(bRetcode < 0) 
{ 

OutputDebugString("HPPRiNTP.DLL DodProp Faiied\i1\r"); 
return(FALSE); 

} 

// Now set default Devmode values In Registry 
pPrtInf o2- > pDevMode = pDevMode; 

bRetcode = SetPrinter(h Printer, 2, (LPBYTE)pPrtlnfo2, O); 

/*** > > Modification to test Printer Driver Switching. End < < *♦*/ 
/***>> L. Snyders 8/29/96 << *♦*/ 



pData = 

{PPRINTPROCESSORDATA)AllocSplMem(si2eof(PRINTPROCESSORDATA)); 

pData->cb = sizeofiPRrNTPROCESSORDATA); 

pData-> signature = PRINTPROCESSORDATASIGNATURE; 
pData->h Printer = hPrinter; 

pData->semPaused = CreateEvent{NULL, FALSE, TRUE,NULL); 
pData->pPrinterName = AilocSplStr(pPrinterName); 
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return (HANDLE)pData; 

} 



// 

// 

// 

UINT ValidateDatatype(LPTSTR pDatatype) 
{ 

LPTSTR FAR •pMyDatatypes = Datatypes; 
DWORD uDatatype = O; 

while (*pMy Datatypes && wcscmp(*pMyDatatypes, pDatatype)) 
{ 

pMyDatatypes + + ; 
uDatatype + + ; 
} 

return uDatatype; 



// 

// 

// 

DWORD 

ValidateBannerType (LPTSTR Ip Banner) 
{ 

if (IpBanner && *lpBanner) 

{ 

if (IwcscmpdpBanner, pFull)) 

return BANNER_FULL; 
if (iwcscmpdpBanner, pSimple)) 

return BANNER_SIMPLE; 

#ifdef TIMING 

if (IwcscmpdpBanner, "Bench")) 
{ 

hWndBench = FlndWindow("BNCH32PRT", "PRTWIN"); 
if (hWndBench) 

SendMessage(hWndBench. WM_USER + 801 , O. 0); 
return O; 

} 

else 

hWndBench = 0; 
#endif 
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return BANNER_CUSTOM; 
} 

return O; 

} 



// — . 

// 

// 

BOOL 
WiNAPI 

WinprlntPrintDocumentOriPrintProcessor( 
HANDLE hPrintProcessor, 

LPPRINTPROCESSORDOCUMENTDATA IpDoc 

) 
{ 

PPRINTPROCESSORDATA pData; 
DOC_INFO_2 Doclnfo; 
DWORD LastError = 0; 
DWORD NoRead, NoWritten; 
DWORD iBannerType; 
BYTE BufferI40961; 
HANDLE hPrinterRead; 
HOC hDC = NULL; 
LPBYTE pReadBuf; 
DWORD cbReadBuf; 
DWORD NoLeftOver = 0; 
BOOL ret = TRUE; 

if (KpData = VaUdateHandle(hPrintProcessor))) ' ! 

{ 

SetLastError { ERRO RJ N V ALI D_H AN DLE) ; 
return FALSE; 

> 

pData->uDatatype = ValidateDatatype(lpDoc->pDatatype); 
iBannerType = ValidateBannerType(lpDoc->pSepFile); 
if (iBannerType) 

lnsertBannerPage(pData- > hPrinter, IpDoc- > Jobid, IpDoc- > pOutputFi| 
iBannerType, IpDoc- >pSepFile); 

Doclnfo. pDocName = IpDoc- >pDocumentName; 

Doclnfo. pOutputFlie = IpDoc- > pOutputFile; // the spool file 
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Doclnfo.pDatatype = lpDoc->pDatatype; 
Doclnfo.JobId = lpDoc-> Jobid; 

// open the same printer for reading the spool file. 

if (IOpenPrinter(pData->pPrinterName, SihPrinterRead, NULL)) 

return FALSE; 

// This makes Read Printer {) read the spool file for us. 

Doclnfo.dwMode = DI_READ_SPOOL_JOB; 

if (IStartDocPrinter(hPrinterRead, 2, (LPBYTE)&Doclnfo)) 

{ 

LastError = GetLastErrorO; 
ret = FALSE; 
goto Exit_2; 
} 

if (pData->uDatatype == PRINTPROCESSOR TYPE RAW) 

{ " " 

// Start direct write to port 

Doclnfo.dwMode = DI_CHANNEL_WRITE; 

if {!StartDocPrinter(pData->hPrinter, 2, (LPBYTE)&Doclnfo)) 

{ 

// SetJob(pData->hPrinter, lpDoc-> Jobid; 0, NOLL, 
JOB_C0NTR0L_CANCEL); 

LastError = GetLastErrorO; 
ret = FALSE; 
goto Exit i ; 

} 
} 

pReadBuf = (LPBYTE)Buffer; 
cbReadBuf = sizeof (Buffer); 



// Here ReadPrinterO is used to actually read 4K of the spool file. 
// This data is then sent either to the printer directly if RAW, 
// or to GDI if EMF. In the later case, the metafilis data is played back 
// on the printer DC and then sent to the printer (all this is done by 
gdiPlaySpoolStreamO). 

while (((ReadPrinter(hPrinterRead, pReadBuf, cbReadBuf, &NoRead)) && 

NoRead) | | NoLeftOver) 

{ 

// gdiPlaySpoolStream now plays one page at a time, 

// So playing back EMF gets opportunity to pause on every page. 

if (pData->fsStatus & PRINTPROCESSOR PAUSED) 
WaitForSingleObject(pData->semPaused, INFINITE); 
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if (pData->fsStatus & PRINTPROCESSOR_ABORTED) 
{ 

// we can not just break for EMF 

// we need to clean up the DC and etc. 

If (pData->uDatatype == PRINTPROCESSOR_TYPE_EMF) 
gdiPlaySpoolStream(NULU NULL, lpDoc->pSpoolFileName, 0, 0, hDC); 

break; 

} 

// check if RAW or EMF, and send it to the right place accordingly, 
if {pData->uDatatype == PRINTPROCESSOR_TYPE_RAW) 

WritePrinter(pData->hPrinter, Buffer, NoRead, SiNoWritten); 
else 

NoRead + = NoLeftOver; 
No Written = NoRead; 

SetLastError{ERROR_SUCCESS); 

// hDC is NULL the first time we get here 
// This is where the metafile is played back. 
hDC = gdiPlaySpoolStream( 
pData->pPrinterName, lpDoc->pOutputFile, 
Buffer, lpDoc->Jobld, StNoRead, hDC); 

// Upon return, NoRead is the number of bytes that are processed 
// in the previous buffer. And it must be no greater than NoWritten. 



if (hDC && (NoWritten > = NoRead)) . , ^ 

{ 

NoLeftOver = NoWritten - NoRead; 

// there may be an incomplete sp block at the. end, that : 
// wasn't processed and we need to carry over ./iV 

if (NoLeftOver) 

Copy Memory (Buffer, Buffer + NoRead,. NoLeftOver); 

pReadBuf = Buffer + NoLeftOver; 

cbReadBuf = sizeof (Buffer) - NoLeftOver; > rv > 

else 

{ 

// we failed 
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// delete the -EMF????.TMP ??? 

// or do we want to leave the EMF around 

// and allow user to retry ??? 

LastError = GetLastErrorO; 

DBGMSG{DBQ_ERROR, ("WinprintPrintDoc: gdiPlaySpoolStream failed 
%d\n", LastError)); 

// prompt user for retry /cancel/ok ? 

gdlPlaySpoolStream(NULU NULL, lpDoc->pSpoolFileName, 0, 0, 0); 
ret = FALSE; 

break; 
} 

} 

} • ■ ^ " 

if (pData->uDatatype == PRINTPROCESSOR^TYPE RAW) 
EndDocPrlnter(pData- > hPrinter); 
Exit_1 : 

EndDocPrinter(hPrinterRead); 
Exit_2: 

ClosePrinter(hPrlnterRead) ; 

if (LastError) 
SetLastError( LastError); 

#ifdef TIMING 
if (hWndBench) 

SendMessage(hWndBench, WM_USER + 802, 0, 0); 
#endif 

return ret; 

} 



// 

II 

II 

BOOL 
WINAPI 

WinprintClosePrintProcessor( 
HANDLE hPrintProcessor 

) 
{ 
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PPRINTPROCESSORDATA pData; 

pData = ValiclateHandle(hPrintProcessor); 

if (IpData) 
{ 

SetLastError(ERRORJNVALID_HANDLE): 
return FALSE; 

} 

pData-> signature = 0; 

Release any allocated resources 

if (pData->hPrinter) 
ClosePrinter(pData->hPrinter); 

CloseHandle(pData- > semPaused) ; 

if {pData->pPrinterName), 
FreeSplStr(pData- > pPririterlSTahne) ; 

FreeSplMem(pData, pData->cb); 

return TRUE; 

} 



// 

// 

// 

BOOL 
WIN API 

WinprintControlPrintProcessor( 
HANDLE hPrintProcessor, 
DWORD Command, 
DWORD JobID, 
LPTSTR pDatatype, 
LPTSTR pSpoolFile 

) 
{ 

PPRINTPROCESSORDATA pData; 
PRINTPROCESSORDATA Data; 

if (hPrintProcessor) 

pData = ValidateHandle(hPrintProcessor); 
else 
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{ 

if (Command I = JOB_CONTROL_CANCEL) 
return FALSE; 

5 

Data, u Datatype = ValidateDatatYpe(pDatatype); 
if (Data.uDatatype > = 0) 

pData = &Data; 
10 else 

pData = 0; 

) 
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if (pData) 
{ 

switch (Command) 

{ 

case JOB_CONTROL_PAUSE: 

ResetEvent(pData- > semPaused); 
pData->fsStatus |= PRINTPROCESSOR_PAUSED; 
return TRUE; 

case JOB CONTROL CANCEL: 



if dhPrintProcessor) 
{ 

30 II we're deleting a job that hasn't started printing 

if (pData->uDatatype == PRINTPROCESSOR TYPE EMF) 

{ - - 

^ return (BOODgdiPlaySpoolStreamCNULL, NULL, pSpoolFile, 0, 0, 0); 
return TRUE; 

} ■ . . •• -. - 



pData->fsStatus \ =. PRINTPRPCESSOR_^ABORTED; 

/• fall through to release job if paused */ 

case JOB_CONTROL_RESUME: 

if (pData->fsStatus & PRINTPROCESSOR PAUSED) 
{ 

50 pData->fsStatus &= -PRINTPROCESSOR PAUSED; 

SetEvent(pData-> semPaused); 
} 
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return TRUE: 
default: 
break; 

} 
} 

return FALSE; 



// 

II 

II 

BOOL 
WINAPI 

WinprintlnstallPrintProcessor( 
HWND hWnd 

) 
{ 

return TRUE; 

} 



// ,^ 

PPRINTPROCESSORDATA 

ValidateHandle( '^^ • ? - ^ ■ " 

HANDLE hQProc 

) 
{ 

PPRINTPROCESSORDATA pData = {PPRINTPROCESSORDATA)hQProc; 

if (pData && pData- > signature = = PRINTPRbCESSORbAf A_SIGNATURE) 
return{ pData ); 



return( NULL ); 



/* file name: local. h •/ 
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• THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT 
WARRANTY OF ANY KIND. EITHER EXPRESSED OR IMPLIED, INCLUDING BUT 
NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR 
FITNESS FOR A PARTICULAR PURPOSE. 

• * 

• Copyright (C) 1993-95 Microsoft Corporation. All Rights Reserved. ♦ 



/ 



// 

// WINPRINT 

#define IDS_BANNERTITLE1 521 
#define IDS_BANNERTITLE2 522 
#define IDS_BANNERJOB 523 
ji^define IDS_BANNERUSER 524 
#define IDS_BANNERDATE 525 
#define IDS_BANNERSIMPLE 526 
#define IDS_BANNERFULL 527 
// 



// , „„. 

// WINPRINT 

#define IDC STANDBAN 600 
#define RT_CLIPFILE 601 



// 

// EXTERN VARIABLES 

// . 

extern HANDLE hinst; 



// DEBUG STUFF 

// 

#ifdef DEBUG 

extern DWORD SplDbgLevel; 

VOID cdecl DbgMsg( LPSTR MsgFormat, ... ); 

/* These flags are not used as arguments to the DBGMSG macro. 

* You have to set the high word of the global variable to cause it to break. 

* It is ignored if used with DBGMSG. 
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* (Here mainly for explanatory purposes.) 
*/ 

#define DBG_BREAK_ON_WARN!NG ( DBG WARNING << 16 ) 
#define DBG_BREAK_ON_ERROR ( DBG ERROR << 16 ) 

#define DBG_NONE 0 
#define DBGJNFO 1 
#define DBG_TRACE DBGJNFO 
#define DBG_WARNING 2 
#define DBG_ERROR 4 

/* Double braces are needed for this one, e.g.: 

DBGMSG( DBG_ERROR, ( "Error code %d". Error ) ); 

« 

* This is because we can't use variable parameter lists in macros. 

* The statement gets pre-processed to a semi-colon in non-debug mod^. 
♦ 

* Set the global variable GLOBAL_DEBUG_FLAGS via the debugger. 

* Setting the flag in the low word causes that level to be printed; 

* setting the high word causes a break into the debugger. 

* E.g. setting it to 0x00040006 will print out all warning, and error 

* messages, and break on errors. 
*/ 



^define DBGMSG( Level, MsgAndArgs ) {if (Level > = SplDbgLevel) {DbgMsg 
MsgAndArgs;}} 

#define DBGBREAKO {DebugBreakO;} 

#define ASSERT( Expr, MsgAndArgs ) {if (lExpr) {DbgMsg MsgAndArgs; 
DebugBreakO;}} 
VOID SpllnSem(VOID); 
VOID SplOutSem(VOID); 



#else 

#define DBGMSG( Level, MsgAndArgs ) 

#define DBGBREAKO 

^define ASSERT! Expr, MsgAndArgs ) 

#define SpllnSemO 

^define SplOutSemO 
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#endif 

// 

// FUNCTION PROTOTYPE 

// 

^define AllocSplMem(a) LocalAlloc( LPTR, a ) 
^define FreeSplMem(a, b) LocalFree( a ) 

LPVOID 

ReallocSplMem( 
LPVOID IpOldMem, 
DWORD cbOld, 
DWORD cbNew 

); 

LPTSTR 
AllocSplStr( 
LPTSTR IpStr 

); 

BOOL 
FreeSplStr( 
LPTSTR IpStr 

); 

BOOL 

ReallocSplStr( 
LPTSTR FAR 'plpStr, 
LPTSTR IpStr 

); 



// . „ 

// UNICODE TO ANSI MACRO 

// ??? Ill we should get rid of these sooner or later 

// . 

#include < string. h> 
^include <stdlib.h> 
#include <stdio.h> 

#ifndef UNICODE 

LPSTR 
mystrstr( 

LPSTR cs, 

LPSTR ct 
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): 

LPSTR 
mystrrchr( 

LPSTR CG, 

char c 

); 



LPSTR 
nnystrchr( 
LPSTR cs, 
^5 char c 

); 



int 

mystrnicmpC 
LPSTR cs, 
LPSTR ct, 
int n 

); 



#define wcscat(a, b) lstrcat(a, b) 
#define wcscmp(a, b) lstrcnnp(a, b) 
#define wcscpy(a, b) lstrcpy(a, b) 
#define wcslen(a) Istrlen(a) 

#undef wcsicmp 

^define wcsicmp(a, b) lstrcmpi(a, b) 



#define wcschr(a, b) mystrchr(a, b) 

#define wcsrchr(a, b) mystrrchr{a, b) 

// #define wcsncmp(a, b, c) strncmp{a, b, c) 

#undef wcsnicmp 

#define wcsnicmp(a, b, c) mystrnicmp{a, b, c) 
^define wcsstr(a, b) mystrstr(a, b) 
#endif // UNICODE // ccteng 



Claims 

1 . An information distributing apparatus usable within a computer network environment (12). comprising: 

a computer (10) having an operating system and configured to operate within the computer network environ- 
ment (12); 

an application (36) configured for running on the computer (10) via the operating system, the application con- 
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figured to generate a source job (28) in the form of an intermediate file format comprising an output instruction 
file (42); 

a print processor (50) in the form of an intermediate executable code for operating on the output instruction file 
(42); and 

5 at least one output device (14, 16. 18) having an output device driver (56) configured to convert the output 

instruction file (42) to output instructions usable by the output device (14, 16. 18) for producing output; 
the print processor (50) being operable on the output instruction file (42) to select the device driver (56) of one 
of the at least one output device (14. 16, 18) to render the output instruction file (42). and feed the output 
instruction file (42) to the output device driver (56) of one of the at least one output device (14, 16, 18). 

2. The information distributing apparatus of claim 1 wherein the output instruction file (42) comprises a drawing 
instruction file containing drawing instructions. 

3. The information distributing apparatus of claim 1 wherein the output device (14, 16. 18) comprises a printer having 
15 a print driver (56), the print driver (56) receiving the intermediate file format of output instructions to process the 

instructions. 

4. The information distributing apparatus of claim 1 wherein the intermediate file format of output instructions com- 
prises an enhanced metafile (42). . ^ 

20 -. ... • ' * 

5. The information distributing apparatus of claim 1 wherein the print processor (50) feeds the output instruction file 
(42) via a serial send to the device driver (56) of one of the at least one output device (14, 16, 18) to render the 
output instiuction file (42) to multiple output de/ices (14, 16, 18). 

25 6. The information distributing apparatus of claim 1 wherein the print processor (50) feeds the output instruction file 
(42) via an interleaved send io the device driver (56) of one of the at least one output device (14. 16. 18) to render 
the output instruction file (42) to multiple output devices (1 4, 1 6. 1 8). 

7. The information distributing apparatus of claim 1 wherein the print processor (50) feeds the output instruction file 
30 (42) via a multiple thread in parallel send to the device driver (56) of one of the at least one output device (14, 16. 

18) to render the output instruction file (42) to multiple output devices (14. 16, 18). 

8. The information distributing apparatus of claim 1 further comprising a registry (54) and a system application pro- 
gramming interface (API) (52). the registry (54) operating through the application programming interface (API) (52) 

35 on the print processor (50) to configure the at least one output device (14, 16, 18) to receive the output instruction 
file (42). 

9. The information distributing apparatus of claim 1 further comprising a memory device (44) and a spooler (46) for 
taking and storing the application generated output instruction file (42). 

40 

1 0. The information distributing apparatus of claim 9 further comprising a graphics device interface (GD I) (40) for imple- 
menting graphical functions and dynamically linking a system graphical application program interface (API) (52) 
with the output device driver (56) of the at least one output device (14. 16. 18), the memory device (44), and an 
original device driver (38) used to generate the output instruction file (42). 

45 

11. The information distributing apparatus of claim 9 further comprising a spool header (48) generated by the spooler 
(46) and assigned to the output instruction file (42), the spool header (48) comprising a spool job header file for 
describing the destinations and rendered/encodings for each destination for the application generated output 
instruction file (42). 

50 

12. The information distributing apparatus of claim 11 wherein the output instruction file (42) comprises an enhanced 
metafile (42). the print processor (50) copies the original copy of the enhanced metafile (60) into the memory device 
(44) after the print processor (50) initiates a print document responsive to the spooler (46), and a feedback loop 
(62) initiates multiple print document tasks comprising multiple pass jobs (64) for distribution. 

55 

13. In a system for distributing print jobs (28) from a computer (10) usable for operating in a computer network environ- 
ment (12) of the type having an operating system: an application (36) configured for running on the operating sys- 
tem and generating a source job (28) comprising an output instruction file (42); and at least one output device (14, 
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16, 18) having an output device driver (56) for receiving ttie output instruction file (42) for producing output, a 
method comprising the steps of: 

providing a print processor (50) in the form of an intermediate executable for operating on the output instruction 
5 file (42); 

retrieving printer details for an identified printer driver (38) name from a memory location in a memory device 
(44) of the computer (10); 

changing the identified printer driver (38) name to a different identified printer driver (56) name of a different 
printer (14. 16, 18); 

10 saving the printer (1 4, 1 6, 1 8) details of the different identified printer driver (56) name in the form of new printer 

information In a system registry (54); 

retrieving printer document properties of the saved printer (14, 16. 18) details from the memory device (44); 
changing the retrieved printer document properties to match new driver (56) settings; 
saving the new printer document properties in the system registry (54); and 
15 allocating and initializing print processor (50) data structures usable to execute a print job (28) on the different 

printer (14, 16, 18). 

14. In the system of claim 13. following initializing the print processor (50) data structures, the Improvement further 
comprising the step of returning to a spooler (46) for reinitializing the system to re-execute another print job (28) via 

20 the aforementioned steps to execute multiple pass print jobs (28) for distribution. 

15. In the system and according to the improved method of claim 13 wherein the output instruction file is embodied in 
the form of an enhanced metafile (42), the method further including the step of providing a spooler (46) for taking 
and storing the enhanced metafile (42) from an application (36), generating a spool header (48) via by the spooler 

25 (46) and assigning the spool header-(48) to the enhanced metafile (42), the spool header (48). comprising a spool 
job header file for describing the destinations and rendered/encodings for each destination for the application (36) 
generated enhanced metafile (42). ; : . 

30 ... . ■ . " ■ 
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